- Bundle.ts now declares `Bundle<T extends Resource = Resource>` with
  `entry?: BundleEntry<T>[]`.
- Added demo tests showing discriminated-union narrowing via
  `Bundle<Patient | Observation>` and backwards-compat default.

Drop the standalone computeGenericInfo helper and the GenericInfo type
in favor of inlining the (small) logic directly into generateType. The
helper duplicated the existing typeFamilyFields detection that already
worked; the genuinely new bit is just the nested-type pass-through.

generateType now returns the parent's GenericParam[] (only paramList is
needed by callers — fieldMap and nestedArgsByField are local concerns),
and generateNestedTypes threads a Record<string, GenericParam[]> back
to the parent.

Net change vs main: +61/-32 (was +81/-36). No behavior change.

Collapse the two-list collection (typeFamilyFields + nestedFields) into
a single discriminated Contribution[] driven by tsIndex.resolveType,
which handles nested and non-nested identifiers uniformly.

- introduce: field type resolves to a typeFamily root → bind a fresh param
- passthrough: field type resolves to a generic nested type → inherit its params

Extract the collection into a free helper (collectGenericContributions)
to keep generateType under the cognitive-complexity cap. Render pass
becomes one loop over contributions; naming policy (T vs TFieldName)
keys off the contribution shape.

Add `generic.params` to `NestedTypeSchema` (with `GenericParam = { name, constraint: TypeIdentifier }`).
Populate during `mkTypeSchemaIndex` after `populateTypeFamily` — for each nested in URL-sorted order,
collect contributions: introduce (field type is a typeFamily root) or passthrough (field type is a
generic-bearing nested with already-populated `generic.params`).

The TS writer reads `target.generic?.params` directly instead of threading a per-pass
`nestedGenericParams` accumulator. `generateType` and `generateNestedTypes` lose their threading
parameter and `generateType` no longer needs a return value.

Behavior change: this fixes an order-dependency in the old writer where a nested type couldn't see
its sibling nesteds' generic params (because they hadn't been generated yet during the sequential
pass). With the IR populated up front, the writer sees the full picture. As a result, e.g.
`BundleEntry` now passes through `BundleEntryResponse`'s generic, becoming
`BundleEntry<TResource extends Resource = Resource, T extends Resource = Resource>` with
`resource?: TResource; response?: BundleEntryResponse<T>;`. `Bundle<T>` itself stays one-param.

Add `sourceField` to `GenericParam` IR type — the field that originally introduced
the param (preserved through passthrough). Naming policy:
- single param → "T" (short)
- multiple params → `T${UpperFirst(sourceField)}` per param

So a param introduced deep in `BundleEntryResponse.outcome` surfaces in `BundleEntry`
as `TOutcome` rather than the local `T`, regardless of how many carrier hops it took
to get there.

Generator-side change: dedup raw params by `sourceField` (not by name). Writer mirrors
the populator's logic for top-level schemas.

Populator now iterates to a fixpoint instead of one URL-sorted pass — passthrough
between siblings means earlier-processed nesteds don't see later siblings'
introduces. Without fixpoint, BundleEntry's IR-stored `generic.params` would be
stale (one param, missing the response passthrough), causing Bundle (top-level) to
emit wrong arity.

Effect on emit:
  Before: BundleEntry<TResource, T> with response: BundleEntryResponse<T>
  After:  BundleEntry<TResource, TOutcome> with response: BundleEntryResponse<TOutcome>
  Bundle now exposes both: Bundle<TResource, TOutcome> with entry: BundleEntry<TResource, TOutcome>[]

Use positional names (T1, T2, …) for multi-param schemas instead of the
sourceField-derived TResource/TOutcome. Single-param schemas still emit "T".

The IR-stored sourceField is preserved (still used to align passthrough args
across nesting hops), only the rendered name changes.

Effect on emit:
  Before: BundleEntry<TResource, TOutcome>; entry: BundleEntry<TResource, TOutcome>[]
  After:  BundleEntry<T1, T2>;             entry: BundleEntry<T1, T2>[]

`path` is now `string[]` carrying the full origin trail from the schema down to
the typeFamily-rooted field that introduces the param. Single-segment for direct
introduce (e.g. `["outcome"]`), grown by passthrough as the param surfaces
through carrier fields (e.g. `["response", "outcome"]`, then
`["entry", "response", "outcome"]`).

Dedup is by leaf segment of the path — multiple fields with the same deepest
origin still share one generic param (so callers narrow once to update many
fields). Param identity stays the same as before; only the IR data is richer.

Naming policy unchanged: single param → "T", multiple → positional T1/T2/….
Writer alignment also matches by leaf segment of `path` (with fallback to the
child param's typeVar) so passthrough args render correctly across nesting hops.